Many computer security systems involve two or more disparate components that communicate with one another. Such a system is only secure to the extent that each component remains secure. For the security system as a whole to be considered trustworthy, it must be known that each communicating component of the system has not been tampered with or spoofed by malicious code or a malicious party. Without a mechanism to verify the integrity of the communicating components, it cannot be know if the security system is being manipulated by an attacker, or whether the information being transmitted is valid.
A Trusted Platform Module (TPM) is a secure crypto-processor chip configured according to a specific, defined standard. One security feature supported by TPM is secure public-key encryption. TPM provides a public and private key pair, which is created randomly on the TPM hardware at manufacture time and cannot be changed. The private key never leaves the TPM chip, while the public key can be used for secure communication with the TPM. Any content encrypted by the TPM's private key can be assumed to be legitimate and secure, as the TPM's private key never leaves the hardware and cannot be accessed from outside of the TPM. Thus, a TPM enables a type of trusted communication, but this is limited in flexibility because the trusted content must be encrypted by the TPM hardware, with a single private key that is static to that hardware.
In the world of virtual computing, multiple virtual machines (VMs or guests) can be instantiated at a software level on a single physical computer (host computer). In various virtualization scenarios, a software component often called a hypervisor can act as an interface between the guests and the host operating system for some or all of the functions of the guests. In other virtualization implementations, there is no underlying host operating system running on the physical, host computer. In those situations, the hypervisor acts as an interface between the guests and the hardware of the host computer. Even where a host operating system is present, the hypervisor sometimes interfaces directly with the hardware for certain services. In some virtualization scenarios, the host itself is in the form of a guest (i.e., a virtual host) running on another host. The services described herein as being performed by a hypervisor are, under certain virtualization scenarios, performed by a component with a different name, such as “supervisor virtual machine,” “virtual machine manager (VMM),” “service partition,” or “domain 0 (dom0).” The name used to denote the component(s) performing specific functionality is not important.
VMware has a security product called VMsafe®, that operates in a virtual computing environment as a security extension of a hypervisor. VMsafe® exposes an API which third parties can use to provide services (including security services) to VMs running in the virtual environment. Such third party services are provided from service VMs, which cannot directly interact with the VMs to which they are providing services, but only through the VMsafe® API. By interacting with the VMSafe® API, a service VM can direct the VMsafe® hypervisor extension to extend a service to a served VM. Because VMsafe® is instantiated at a hypervisor level, it is isolated from both the VMs providing services through VMsafe® and from the VMs to which the services are being provided. The VMsafe® hypervisor extension can be thought of as a container that extends services from third party service VMs to served VMs without requiring or allowing direct communication between the two. This provides a level of isolation between the VMs, such that a service providing VM (referred to as a security VM, or SVM in VMware) cannot directly be accessed (and, for example, corrupted) by a served VM. To provide a service to target VMs, the VMsafe® hypervisor extension instantiates and directs companion components within the VMs receiving the service. It is to be understood that VMsafe® is a specific example of a commercial product providing a hypervisor security extension container, and this functionality could be provided by other products from other companies with different trade names.
Although VMsafe® provides a level of isolation between VMs, it does not ensure that information exchanged between the security enhanced hypervisor extension container, the VMs providing the services, the VMs receiving services, the VM companion components and any remote servers is legitimate and has not been tampered with by one of the various components involved in the communication. In other words, with or without a hypervisor security extension container, a system of communicating computer components can only be considered secure where each component is known to be secure. It would be desirable to address these issues.